Mobile device applications typically operate in a client-server model, where the application client on a mobile device receives and processes data from one or more network-based application servers. To obtain the data from the server, the application client may use either a pull or push mode. In the pull mode, the application client periodically polls the application server for new data. In the push mode, the application server “pushes” data to the application client when the new data is available, without the need for the application client to poll.
Applications that often poll the network can benefit from push services. Push services include traditional e-mail (e.g., for sending a push notification to a mobile device when new e-mail arrives at the server), Short Messaging Service (SMS) (e.g., for sending a push notification when an SMS message arrives at a server), voice over internet protocol (VoIP) (e.g., for notification of an incoming call), web browsing (e.g., for notification of when to refresh the web page), and growing video applications for 3G/4G smart mobile devices. Examples of push event notifications for such video applications include, but are not limited to, network condition changes, policy changes, and other notifications that may require an application client response.
Push mode is especially important for mobile devices operating over cellular networks. Typically, when a mobile device does not have data to send or receive, it can go into an idle (e.g., dormant, sleep) mode to conserve battery power and over-the-air resources associated with the device's radio operation. The radio access network maintains location state information of the idle device and uses paging mechanisms defined by a corresponding cellular access technology standard to wake up the mobile device when data arrives for the device.
In contrast, pull mode requires a mobile device to periodically exit idle mode when the application client needs to poll the application server for new data, regardless of whether the server has such new data or not, resulting in waste of mobile device battery resources and unnecessary over the air communications. Further, improving application response time requires increasing polling frequency with more battery and over the air resources wasted. Reducing polling frequency can result in more delays in application client responses to application server events.
With 3G and 4G networks using all IP-based data services, the typical network architecture for current cellular service providers uses private IP addresses for the mobile devices, with a firewall between the service provider core network and the public internet. This presents a significant challenge for push implementations. A typical firewall with network address translation (NAT) located between the application client on the mobile device (with a private IP address) and the application server allows only for transmission control protocol (TCP) based client-initiated communications between the application client and application server. However, maintaining such TCP connections between the application client and application server requires periodic “heart-beating”, which is essentially equivalent to a pull mode (client-originated TCP packets have to be exchanged periodically), with a similar impact as pull mode on the mobile device idle mode.
With an application client that has a private IP address behind a firewall, an application server located outside the firewall cannot send IP packets to the application client without a special “hole” in the firewall, since the client's private IP address is not reachable from the outside of the service provider's network. Such a “hole in the firewall” is typically created automatically when a TCP connection with the application server is originated by the application client. The firewall NAT function replaces in the client sent TCP/IP packet, the pair <source IP address, source TCP port number> with the pair of <public IP address common for many clients+unique new source TCP port number> and creates for a certain duration of time a mapping between the pair <source IP address, source TCP port number>, and the <unique new source TCP port number>, thus allowing packets from the application server addressed to the <public IP address common for many clients+unique new source TCP port number> to be forwarded to the <source IP address, source TCP port number> of the application client. Such mapping creates a “hole” in the firewall allowing the application server to send packets to the application client. In the absence of TCP traffic (e.g., when the client goes to idle mode), the mapping ages out and the client becomes unreachable from the server. However, maintaining a persistent TCP connection by sending periodic TCP traffic to refresh this mapping is costly and requires the mobile device to periodically exit the idle state to generate such traffic. Also, the “aging” timers configuration may vary for different firewalls, resulting in a requirement for such traffic to be unnecessarily frequent.
Existing solutions indicate the importance of firewall issues, but also that there is no single satisfactory approach for a push implementation with a firewall between a service provider network and the public internet.
For example, a TCP-based mobile operating system (OS) or mobile device vendor push service typically consists of a push server located elsewhere in the internet (outside of the wireless service providers firewall-protected core), push client middleware coupled with the mobile device OS, and a set of APIs specific to the mobile device OS that are exposed to the application clients and servers to register and receive push service. However, a persistent TCP connection has to be maintained through the firewall. Maintaining such a connection requires periodic TCP traffic to be exchanged between the mobile device and the push server, resulting in a waste of both battery life and over-the-air resources. Depending upon the frequency of the TCP keep-alive (in some cases it is every second) and/or firewall aging refresh exchanges, the mobile device is either completely prevented from entering the idle mode (if the keep-alive exchange is too frequent) or is forced to periodically exit the idle mode for the keep-alive exchange. The frequency of the TCP exchange is typically dictated by OS-specific considerations (e.g., TCP keep-alive or other mechanisms that allow a server to detect a dead TCP connection when the mobile device powers down or abruptly goes out of wireless coverage range) as well as by a firewall hole aging timer for the reverse TCP traffic from the server to the client. Also, maintaining persistent TCP connections with tens of millions of mobile clients requires significant server resources to be allocated. In addition, this method may create privacy issues for the mobile device users, as it may allow the third-party push server to track mobile devices and their use of applications.
FIG. 1 illustrates a functional diagram of a mobile network for implementing a persistent TCP connection-based vendor-controlled push service. The network 100 generally provides mobile network services (e.g., voice, text, video and other data services) through the use of private IP addresses for one or more mobile devices 102. Mobile devices 102 are configured to run a mobile device operating system (OS) and various mobile network service applications utilizing customized, vendor-implemented push services. The network 100 includes a firewall 104 with network address translation (NAT) between a mobile service provider's core network 106 and the public Internet 108. Core network 106 includes components typically used for implementing an LTE mobile communications system such as a packet data network gateway (PDN-GW) 110, home subscriber server (HSS) 112, mobility management entity (MME) 114, serving gateway (S-GW) 116, and one or more eNodeB cellular access points 118. However, core network 106 may be a 2G, 3G (e.g., WCDMA-UMTS, CDMA) or 4G (e.g., LTE, WiMAX) network with components configured to implement any such standards-defined network architecture. Therefore, while FIG. 1 illustrates an LTE mobile communications system, one skilled in the art will recognize that one or more of these components, and various other well-known components, may be added or combined for implementing a 2G, 3G, 4G or other mobile communications system network architecture.
Network 100 can further include a push server 120 accessible via the public Internet 108 outside of firewall 104. Mobile devices 102 can include push client 122 (e.g., middleware coupled with the mobile device Operating System (OS)), and one or more application programming interfaces (APIs) 124 that are exposed to application client 126 and application server 128 for registering and receiving push services specific to mobile device/OS vendors via a persistent TCP-based connection. For example, a mobile device 102 may periodically “wake up” to send a heartbeat-type communication to maintain a TCP-based connection.
In network 100, application server 128 cannot send IP packets to a mobile device 102 that has a private IP address without a special “hole” in the firewall (i.e., the client's private IP address is not reachable from outside of the service provider's core network 106). For example, such a “hole” in firewall 104 may be created automatically when a TCP-based connection with application server 128 is originated by a mobile device 102. Specifically, a firewall NAT function replaces a private address/port number pair, for example <source IP address, source TCP port number>, with a public address/port number pair, for example <public IP address common for many mobile devices+unique new source TCP port number>, in a TCP/IP packet sent by a mobile device 102, and creates (e.g., for a certain duration of time) a mapping between the pair, <source IP address, source TCP port number>, and the unique new source TCP port number. As such, application server 128 may send packets addressed to the <public IP address common for many clients+unique new source TCP port number> that may be forwarded to the private address/port number pair, <source IP address, source TCP port number>, of a specific mobile device 102. This mapping procedure, defined as creating a “hole” in the firewall, allows application server 128 to send packets to application client 126. However, in the absence of TCP-based communication traffic (e.g., when a mobile device 102 toggles into idle mode) the public/private mapping may expire, meaning that application client 126 will become unreachable from application server 128.
A User Datagram Protocol-based Session Initiation Protocol (UDP-based SIP) model requires a special session border controller device to operate in conjunction with a firewall to dynamically “punch” holes in the firewall to reach a mobile device during mobile device registration on the network. This method allows a mobile device to receive incoming calls. However, a UDP-based SIP model may also require a specialized session border control function for each new application and a reconfiguring of the session border controller each time a new application appears on the market.
SMS messages also may be utilized for push notifications for non-SMS instant message applications. However, many service provider plans charge users for receiving SMS messages. Therefore, using SMS for push notifications may cause unexpected and unwelcome charges for users with such plans.